home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2414 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.8 KB
  1. Path: grafix.xs4all.nl!john.hendrikx
  2. Date: Tue, 30 Jan 96 18:51:40 GMT+1
  3. Newsgroups: comp.sys.amiga.programmer
  4. Distribution: world
  5. Subject: Re: Demo/game to OS friendly part II
  6. MIME-Version: 1.0
  7. Content-Type: text/plain; charset=iso-8859-1
  8. Content-Transfer-Encoding: 8bit
  9. From: john.hendrikx@grafix.xs4all.nl (John Hendrikx)
  10. Message-ID: <john.hendrikx.4ai4@grafix.xs4all.nl>
  11. Organization: Grafix Attack BBS Holland
  12.  
  13. In a message of 29 Jan 96 Peter McGavin wrote to All:
  14.  
  15.  >> that accessing the screen-buffer directly is a necessity for fast games,
  16.  >> like a DOOM clone, as they want to do stuff on a pixel basis which the
  17.  >> OS doesn't provide standard functions for (unlike line-drawing for
  18.  >> example).
  19.  
  20.  PM> Personally I would like to see what seems a completely opposite approach
  21.  PM> (for RTG).  That is, I think gfx should be implemented something like
  22.  PM> DOS.  Gfx primitives like Draw(), SetAPen(), Text(), etc, internally
  23.  PM> should use message-passing and packets.  The Amiga has a big advantage
  24.  PM> over other platforms that messages don't have to be copied. 
  25.  
  26. This advantage is likely to go away in the near future with a new OS version or
  27. soon after that.  AT would be wise not to rely too much on these 'side-effects'
  28. of a system which is not memory-protected.
  29.  
  30.  PM> Applications can choose either synchronous or asynchronous interfaces. 
  31.  PM> Gfx card drivers would have standard async BeginIO() functions.  The
  32.  PM> main advantages are:
  33.  
  34.  PM>  o  This allows much better high-level _async_ graphics than the
  35.  PM>     current implementation.  Applications don't have to wait for
  36.  PM>     each primitive to finish before they queue the next one.  Indeed,
  37.  PM>     an application could queue hundreds or thousands of operations
  38.  PM>     in advance, then carry on with something else while the gfx
  39.  PM>     system catches up.  Another scenario is that the application
  40.  PM>     queues only a few, large operations, such as a single, large,
  41.  PM>     WritePixelArray8() which operates with async DMA and uses no
  42.  PM>     CPU time.  Thus, gfx coprocessors and DMA can be better
  43.  PM>     utilised;
  44.  
  45. The blitter is a good example of this in Amiga right now.  It is async, when
  46. you draw a line with the blitter usign DrawLine() there is no guarantee that
  47. when the function returns that the line is already drawn.  You have to wait for
  48. the blitter to make sure.
  49.  
  50.  PM>  o  Gfx redirection across networks would be relatively trivial
  51.  PM>     (much like X11).
  52.  
  53. Well, this would be none too hard even in the current system if NOBODY used the
  54. hardware but used the provided functions.  These could then be patched to pass
  55. on their info to another machine via a network.
  56.  
  57.  PM>  o  It makes less assumptions about the underlying hardware.  Gfx
  58.  PM>     hardware doesn't even have to be memory-mapped.
  59.  
  60. That's basicly RTG.
  61.  
  62.  PM>  o  It is more straightforward to share the same hardware between
  63.  PM>     multiple tasks this way.
  64.  
  65. Yes, but it would also involve passing a message for each gfx-action, while the
  66. current system, although less straightforward can just queu gfx-actions in a
  67. list (some current blitter functions do this) which achieves much the same
  68. effect.
  69.  
  70.  PM> But how could we reconcile such an interface with a system that allows
  71.  PM> direct hardware poking?  (and which won't work with "non-standard" gfx
  72.  PM> hardware or networks, BTW.)
  73.  
  74. I think RTG will do what you want just fine, what you're suggesting would just
  75. make things even slower although it has some advantages.
  76.  
  77. I like to point out though that I don't consider accessing buffer memory for
  78. gfx or sample-data 'hardware poking'.  I think that apps should be allowed to
  79. use this memory (in a very controlled way) but when I say apps I really mean
  80. apps which require this kind of low-level buffer access (for speed) like a game
  81. for instance, or sample-mixing software for example.
  82.  
  83. The only thing I really want to see completely banned is poking registers which
  84. in some way affects the gfx-card's (or sound card's and so on) behaviour. 
  85. Accessing registers should be left strictly to the device-driver (ie, the OS).
  86. Writing new device drivers is possible of course but a normal app should only
  87. be able to go through the device driver.
  88.  
  89. As poking registers is usually a very small part of CPU time used by games (and
  90. some apps) I think the overhead to let the OS poke the registers for you
  91. (although it should be completely abstract, not like some current graphics are
  92. now) is minimal.  A good example of this is that games often use their own
  93. waitblitter routine, while calling WaitBlit() certainly won't have any impact
  94. on overall speed of the game at all.
  95.  
  96. Grtz John
  97.  
  98. -----------------------------------------------------------------------
  99.  John.Hendrikx@grafix.xs4all.nl   TextDemo/FastView/Etc... development
  100. -----------------------------------------------------------------------
  101. -- Via Xenolink 1.981, XenolinkUUCP 1.1
  102.